System and method for real-time options trading over a global computer network

ABSTRACT

The present invention relates to a method and system for electronically trading a financial instrument. The method includes entering a bid order for the financial instrument and placing the bid order in a bid queue associated with a buyer who maintains a list of sellers to sell the financial instrument to. Then, entering an ask order for the financial instrument and placing the ask order in an ask queue associated with a seller who maintains a list of buyers to buy the financial instrument from. Next, the present invention will match the bid order and the ask order and to execute a trade between the buyer and the seller. Lastly, the trade is executed if the bid order is not less than the ask order, and if the buyer is on the list of buyers and the seller is on the list of sellers.

RELATED APPLICATIONS

[0001] The present application claims priority from U.S. ProvisionalApplication No. 60/286,807 filed Apr. 26, 2001, entitled “A SYSTEM ANDMETHOD FOR REAL-TIME OPTIONS TRADING OVER A GLOBAL COMPUTER NETWORK”.

FIELD OF THE INVENTION

[0002] The present invention relates to online systems and methods and,more particularly, to systems and methods that facilitate real-timeoptions trading over a computer network, such as the Internet.

BACKGROUND OF THE INVENTION

[0003] Options are legally binding agreements that grant the holder theright, but not the obligation, to buy or sell a financial instruments(i.e. commodities like crude oil, cotton, and wheat) on a particulardate some time in the future at a set price. Options contracts generallyhave standard quality, quantity, delivery time and location dependingupon the type of underlying commodity associated with them. The only“negotiated” variable is price (or “premium”), which has traditionallybeen discovered on the floors of futures exchanges, such as the ChicagoBoard of Trade through the open outcry auction market system. Thisprocess allows buyers and sellers to consummate trades by offeringverbal bids and offers.

[0004] Certain terminology is essential in the field of option trading.A CALL is the right, but not the obligation to buy, for instance, anunderlying commodity at a specific price (strike price) up until aspecific time in the future (expiration date). A PUT is the right butnot the obligation to sell the underlying commodity at a specific priceup until a specific point in the future. A CALL SPREAD is when yousimultaneously buy one call and sell another. An example would be thesimultaneous buying of a May 50 call and selling of a May 55 call. Ifthey were in different months it would be a known as CALENDAR CALL. Thisis a spread which would be the simultaneous buying of a May 50 call andselling of a July 50 call. A STRADDLE is the simultaneous buying of acall and a put of the same strike in the same month. So one would bebuying say, a 50 call and buying the 50 put. Another trade type is aFENCE, which would be the simultaneous buying of a put and selling acall (or selling the put and buying the call). If one executes thesetrades in different months it is a “calendar” fence. Many option tradesare carried out by combining multiple calls or puts in various differentcombinations (such “multi-leg”). Other trading types have colorful namessuch as butterflies, strangles, calendar spreads, christmas trees,condors, iron butterflies, etc. each involving different tradingstrategies. For instance, a BUTTERFLY is the sale (purchase) of twooptions with the same strike price, together with the purchase (sale) ofone option with a lower strike price and one option with a higher strikeprice. All options must be of the same type (call or put), have the sameexpiration date and, there must be an equal increment between strikeprices. Some types of options trades and strategies could have even say12 legs. Every trade or option strategy is just a combination of callsand puts and one must have an understanding of each option type—itspattern and how many legs it would have.

[0005] The open outcry system allows for quick assimilation of marketinformation where buyers counterbalance sellers and ultimately arrive ata fair market value for the contracts. However, the open outcry systemdoes not always provide for price transparency—making it difficult forsome consumers to directly participate in the process. Furthermore, asthe volume and volatility of the futures market continues to increase,it is becoming more difficult to handle the administrative challengespresented by the open-outcry system. For these reasons, among others,there is a need for a different approach to options trading.

[0006] One potential solution is the use of an electronic order entrysystem. However, unlike open-outcry, traders in a computerized settingcannot “see” the market participants; “feel” the interest in aparticular instrument. Thus, there is a need for an electronic ordersystem that provides human market participants with the feel of anexchange floor with the convenience of computerized organization.

SUMMARY OF THE INVENTION

[0007] The present invention relates to a method and system forelectronically trading a financial instrument. The method includesentering a bid order for the financial instrument and placing the bidorder in a bid queue associated with a buyer who maintains a list ofsellers to sell the financial instrument to. Then, entering an ask orderfor the financial instrument and placing the ask order in an ask queueassociated with a seller who maintains a list of buyers to buy thefinancial instrument from. Next, the present invention will match thebid order and the ask order and to execute a trade between the buyer andthe seller. Lastly, the trade is executed if the bid order is not lessthan the ask order, and if the buyer is on the list of buyers and theseller is on the list of sellers.

[0008] A further method and system of the present invention relate toelectronically trading options contracts and hedging the optionscontracts with futures contracts. The method includes entering a buyorder for options with a first hedge delta to represent a first numberof futures. A sell order is entered for options with a second hedgedelta that represents a second number of futures. Then the buy order andthe sell order are matched so a trade can be executed. Lastly, the tradeis executed if the first hedge delta matches the second hedge delta.

[0009] Another embodiment of the present invention is a system andmethod for real-time options trading over a global computer network,such as the Internet. In particular, the present invention discloses asystem for real-time trading of options contracts between a plurality oftraders over a computer network. The system includes a computer network,a market server, and two or more trader clients.

[0010] The market server is connected to the computer network. Themarket server additionally processes and executes matched trade ordersin substantially real time. The market server may also precludeexecution of a trade based on credit available to the human trader.

[0011] The two or more trader clients are connected to the computernetwork so each of the trader clients can be placed into communicationwith the market server. Each of the trader clients facilitates entersand transmits commands in substantially real-time to the market serverand displays substantially real-time updates from the market server.Each of the trader clients further provides information to the humantrader regarding a desired underlying commodity market as received fromthe market server. Each trader client may then display the underlyingcommodity information in a working order and filled order windows. Theunderlying commodity information is alternatively available to the humantrader in both summary and detailed form.

[0012] The trader client's commands may include trade orders wherein themarket server distributes the trade orders and any executions of same toeach of the trader clients in substantially real-time. Each traderclient facilitates the entry of commands by providing a graphical userinterface. The trader client may also facilitate the entry of thecommands by providing a simplified order entry language.

[0013] A further embodiment of the present invention discloses a methodfor real-time trading of options contracts between multiple traders onan underlying commodity over a computer network using a client-serversystem having multiple clients. The method includes submitting commandsto the server, acting upon the commands submitted from multiple clientsat the server, and displaying all information from the server regardingthe submitted commands. Traders enter the commands that are submitted tothe server. The commands entered are issued from multiple clients inregard to the underlying commodity. Providing multiple command entrymethods may facilitate the submission of the commands. One such entrymethod involves using graphical user interface principles. Another suchentry method involves a quick entry language.

[0014] Acting upon the commands submitted includes matching trade ordercommands of at least two traders according to a set of rules insubstantially real-time. Acting upon the commands further includesvalidating commands prior to acting further on the command.

[0015] Information from the server regarding submitted commands relatedto the underlying commodity and resulting server actions is displayed insubstantially real-time on all of the multiple clients. The displayfurther includes parsing the information into multiple windows dependingupon the status of the order.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

[0016] The above and still further objects, features and advantages ofthe present invention will become apparent upon consideration of thefollowing detailed description of a specific embodiment thereof,especially when taken in conjunction with the accompanying drawingswherein like reference numerals in the various figures are utilized todesignate like components, and wherein:

[0017]FIG. 1 is a block diagram overview of the various components ofthe present invention;

[0018]FIG. 2 illustrates a potential configuration of informationwindows in a graphical user interface in accordance with one potentialembodiment of trader client;

[0019]FIG. 3 illustrates a potential “trade” pull-down menu that may beused in the main application screen of trader client;

[0020]FIG. 4 illustrates a potential order entry dialog box that may beused in an embodiment of the trader client;

[0021]FIG. 5 illustrates a potential “view” pull-down menu, of anembodiment, that may be used in the main application screen of traderclient;

[0022]FIG. 6 illustrates an Option Detail Screen of the trader clientfor one potential embodiment;

[0023]FIG. 7 illustrates a View Market Window of the trader client foran embodiment;

[0024]FIG. 8 illustrates a non-exclusive list of Quick Entry languagecommand syntax;

[0025]FIG. 9A illustrates a potential configuration of informationwindows in a graphical user interface of the trader client for oneembodiment;

[0026]FIG. 9B illustrates a confirmation message dialog box associatedwith operation of the kill all orders feature of an embodiment of tradeclient;

[0027]FIG. 10A illustrates a potential order entry dialog box embodimentof the trader client; and

[0028]FIG. 10B illustrates another embodiment of an order entry dialogbox that may be used in the trade client.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0029]FIG. 1 is a block diagram overview of the various components ofthe present inventive system. In particular, system 100 includes marketserver 101, trader clients 200 a-n, administrator clients 300 a-n, and aserver administrator 400. It is critical to the present system that atleast market server 101 and each of trader clients 200 a-n are able tocommunicate in real-time.

[0030] As illustrated in FIG. 1, each of trader clients 200 a-n,administrator clients 300 a-n and server administrator 400 are connectedto market server 101 via computer network 110. Computer network 110 isany computer network that allows multiple computer systems tocommunicate with each other such as a Local Area Network (LAN), a WideArea Network (WAN), an intranet or the Internet using standardcommunications protocols. It should also be noted that computer network110 could comprise the public telephone network with market server 101acting as a dial-up bulletin board and the trader clients 200 dialing indirectly to market server 101 via a telephone network. Each traderclient 200 can be connected to market server 101 using any of theforegoing types of networking approaches and none need to connect viathe same networking approach.

[0031] Trader clients 200 a-n each preferably run on a general-purposecomputer system such as an IBM compatible, Apple, or other equivalentpersonal computer that allows a potential trader to communicate withmarket server 101 via computer network 110. The general-purpose computersystem further includes a network interface that allows forcommunications with the computer network and may include any Internetcapable software program such as Netscape© Navigator©, Microsoft©Internet Explorer©, Mosaic©, or their equivalents.

[0032] The market server 101 is preferably a general-purpose computersystem such as an IBM© compatible, Apple©, Unix type workstation, ortheir equivalents that can facilitate inquiries from multiplesimultaneous inquiries. Market server 101 must also have a networkinterface that allows for communications with the computer network andmay include Internet server software. It is known in the art that themarket server 101 and trader clients 200 a-n need not be running on thesame type of general-purpose computer for the present system to beoperational.

[0033] Once the trader client 200 is connected to the market server 101,users will access various user interfaces, which may take the generalform depicted in FIGS. 2 through 7. These figures suggest the use ofJava applets in a Microsoft© Windows© environment but it is apparent tothose skilled in the art that numerous other environments can be used.Other programming languages and user-interface approaches may also beused to facilitate data entry and execute the various computer programsthat make up the present invention.

[0034] Market server 101 is the focal point and final arbiter for orderprocessing and trade execution with respect to sequencing and timing. Inparticular, market server 101 should:

[0035] Accept, process, store and distribute “Request for Quotes”(“RFQs”), quotes, orders, executions, confirmations, and rejections andother system messages in real-time;

[0036] Maintain a repository of market participant information (users,traders, administrators);

[0037] Screen trades based on party identity;

[0038] Maintain message and activity logs suitable for history and tosupport billing purposes;

[0039] Facilitate instant messaging from market server 101 to traderclient 200 users for system status and system announcements;

[0040] Provide price transparency by distributing all quotes and ordersin a particular Underlying market (e.g. natural gas, cotton, gold,stocks); and

[0041] Provide settlement support including reporting of firm wide andper user activity on the system to allow easy integration with eachfirm's settlement systems.

[0042] The market server 101 may also provide:

[0043] Limited anonymity (market participants may choose not to identifythemselves to other participants before the trade, and need only revealtheir identities to counterparties after the trade);

[0044] Credit Facility interface (trades may be approved in real-time bythird-party guarantors);

[0045] Distribution of market updates through e-mail, fax and pager;

[0046] Trade screening based available credit and firm-assigned risk;and

[0047] Cash settlement facilities.

[0048] Market server 101 includes a user entitlements handler that mapsuser IDs associated with incoming messages and other service requestswith the stored security permission information related to the user typeof the user making the request in order to authenticate users to themarket server, and toward checking whether the user ID is entitled toperform the requested operation.

[0049] The market server 101 further includes an order matching handlerfor reviewing all currently active orders and quotes, executing anytrades possible according to pre-programmed matching rules, modifyingorders and quotes according to the matching rules, and providingconfirmation to all traders effected by the resulting trades. Inparticular, a trade will occur when the “Right Price Queuing” rule issatisfied. In a preferred embodiment, a trade will not occur unless the“Right Counterparty Rules” is simultaneously satisfied.

[0050] Financial instruments can only be traded among themselves; theycannot trade with another instrument that differs from them in anydetail, except that hedged instruments need only match on the net delta.To facilitate these trades, each instrument has a bid queue consistingof bids and an ask queue consisting of asks. Thus, when a bid on aparticular instrument reaches the market server 101, it is placed in thebid queue for that instrument after execution of any pending trades. Theplacement of the instrument is based on a number of factors. Somefactors may include the price, a better price move further forward inthe queue, and time, earlier bids stay ahead of later bids of the sameprice. As a result, the best bid, which may be the highest bid, isplaced on the front of the bid queue. Likewise, when an ask on aparticular instrument reaches the market server 101, it is placed in theask queue for that instrument. Again, the placement of instrument isbased on a number of factors. The placement factors may include the bestask, which is the lowest offer, being placed at the front of the askqueue.

[0051] A bid or ask order may remain in its queue until a certain eventis satisfied. Those events may include the order being:

[0052] a. traded in the market server 101;

[0053] b. killed by submitting trader;

[0054] c. modified by a trader (subject to certain exceptions describedbelow); or

[0055] d. removed by the system either because of an administrativeactivity or because the order has timed out.

[0056] Preferably, a quote lives in the queue like a market order,except that it removes itself from the queue after a fixed time limit.This time limit may be short, approximately 10 seconds or may belengthened or decreased. A key factor in determining the time limit isthat the longer the quote is maintained in the queue, the more likely itwill be stale.

[0057] The order may traded when Best Bid>=Best Ask, which may satisfythe Right Price Queing Rule, with the trade price being the best ask.The number of contracts that trade as a result of a match is the lowerof the best bid size and the best ask size. Consequently, if the bestbid size and the best ask size are different, the lower of the two willbe completely filled, and the higher of then two will be “partiallyfilled” with a remainder. If a partially filled trade of instrumentsinvolving Hedged Contracts would result in a fractional hedged quantitybeing traded, then the orders may not match. In certain instances, thesystem may still match the trade if the deltas match. This may result inthe generation and submission, to the market, of partial fills withalternate delta mixes in order to achieve the desired result. Every timethe best bid or best ask changes which may be represented by a change inthe order at the front of the bid or ask queue, the System verifies ifit can execute the trade, and will keep trading until best bid<best ask.The number of contracts that have been traded is reported to allcounterparties.

[0058] In one embodiment, each Firm F in market server 101 has aCounterparty List (CL) that consists of other Firms F1, F2, . . . Fnthat firm F may accept as potential counterparties to a trade. Thus,each market bid in the bid queues is associated with the submittingtrader 50 and the submitting trader's Firm. Then, the market server maycompare both the best bid/best ask and the Firm for any one offer. Evenif the Right Price Queuing Rule indicates that two orders should trade,each party must also be in the other's Counterparty List. So, if thebest bid firm does not have the best ask firm in its counterparty listor the best ask firm does not have the best bid firm in its counterpartylist, the trade will not execute. This is known as the “Right CreditCounterparty Rule.”

[0059] The fact that the trade could not be executed is thencommunicated to both the buyer and seller by an electronic message. Themarket server 101 will then continue past that unexecutable bid-askmatch to the next order in the respective queue and attempt to satisfythe Right Price Queing Rule and then again try and satisfy the RightCredit Counterparty Rule. No orders are removed from the queues forfailure to satisfy some firm's right credit counterparty rule.

[0060] Market server 101 will validate all messages sent by traders tothe market server 101 before being placed in either queue. Messages thatdo not pass validation are rejected, and a rejection message is sentback to the trader client 200 of the sending user. The trader client200, in addition to the validation performed by the order validationservice at the market server 101, also performs some validation. Thisdouble validation is desirable to provide both timely feedback to theuser during the order entry process, and to provide an independent andreliable back-end service. This and other validation or screeningprocesses can be performed electronically to both buyers and sellers.Thus, a party can have pre-set rules to electronically validate acounterparty, and if that criteria is met, the counterparty is added tothe acceptable list of buyers/sellers.

[0061] Trader client 200 provides a computer interface for a humantrader 50 to enter and transmit commands (i.e. RFQs, quotes, orders) tomarket server 101; receive and display updates from market server 101;and to submit information inquiries regarding the past and current stateof the market, all in substantially real-time. In one approach, traderclient 200 allows trader 50 to customize screen layouts, andautomatically restores the most recent screen layout upon login. Asample layout is illustrated in FIG. 2.

[0062] In a preferred approach to the system 100, a login includesselection of a particular underlying market for the present tradingsession. With this approach, a trader 50 could enter the market fornatural gas or precious metals. In such an approach, the trader 50 wouldbe required to exit one underlying market to enter another underlyingmarket. Other approaches may include the ability for multipleinstruments to be traded in one session.

[0063] After a successful login, a series of information windows appear.One potential configuration is illustrated in FIG. 2. This configurationmay be configured by human trader 50 from a standard configuration toany configuration of the human trader's preference. As would beunderstood by those of ordinary skill in the art, the number of windowsthat can be simultaneously displayed is limited by physical screen sizeand readability of the contained text. As is also known, windows may betiled, cascaded and hidden behind other windows and later brought intoview by standard operating system techniques.

[0064] As illustrated in FIG. 2, the information windows can includemain application screen 220, which has a menu bar 222 containing atleast “trade,” 224 “view,” 226 and “time & sales” 228 menus. Othercommands may also be provided on the menu bar, such as a pull-down“help” menu to provide on-line documentation and information regardingsystem 100 and trader client 200, and options to print the data in thecurrently active window, exit trader client 200 and set workstationcustomization options (e.g. displayed windows, prompt messagingactivation and reception of alert messages).

[0065] The approach illustrated in FIG. 2, the trader client 200 mayhave a “trade” pull-down menu 224 provided to facilitate quick creationof various options contract types. These types may include, but notlimited to the most commonly used types (e.g. calls, puts, call spreads,put spreads, fences, strangles or straddle)).

[0066]FIG. 3 illustrates a sample “trade” pull-down menu 300. The menuis multi-layered 302, 304 to further facilitate quick creation ofcontracts. It is preferable for these menu selections to be furthersupported by a dialog box tailored to the selected option type, such asprovided via a new order entry card. For instance, the dialog box 400illustrated in FIG. 4 would be populated (and/or modified) based on thepull-down menu selection.

[0067] In a preferred embodiment, system 100 supports trading of inexcess of 100,000 different options types over the course of 240 months(a 20 year window from the current date) in various underlying markets.The number of options and available months, of course, is a matter ofdesign choice. Regardless of the volume of information, human trader 50may wish to focus on a segment of the market in determining upcomingtrading strategy.

[0068]FIG. 5 illustrates the “view” menu 500, which offers a mechanismfor human trader 50 to review selected portions of trader 50's pasttrading history on the computer screen. For instance, in one approach totrader client 200, the “view” pull-down menu 500 facilitates quickselection of months 502 and contract types 504 using multi-layeredpull-down menus. Alternatively, trader 50 may selected a particulartrading date, which would result in the display all trades transacted bytrader 50 on that date, as illustrated in FIG. 7. Other approaches todisplaying and selecting alternatives from a list are well known tothose in the graphical user interface art and may also be used tofacilitate this functionality.

[0069] The main application window 220, illustrated in FIG. 2 furtherincludes a “Time & Sales” menu 228 which displays the status of all thehuman traders in the current market. Thus, both “view” and “Time &Sales” menus display the same types of data, with an exemplary viewwindow illustrated in FIG. 7. Similarly, the same type of multi-layeredpull-down menus provided under the “view” menu 500 exemplified in FIG. 5would likewise be provided for the “Time & Sales” menu 228. Of course,it would be understood to those in the art that other displays and meansfor filtering the displayed information may be used.

[0070] At the bottom of the main application screen 220 (FIG. 2) is astatus bar 230. The status bar 230 is preferably divided into twosections. The first section is a message area that displays any relevantinformation for the user (e.g. “Submitting order to market server”,“Order acknowledged by market server, Order number is ABCD123”, “Orderrejected by market server. Invalid option types ‘XC”’, “Order ABDC123executed”, “Submitting modify request to market server for order ABCD124. . . ”, and “Modify request received for order ABCD124.”) The statusbar message area may also retain a history of the messages it hasdisplayed. As is known in the art, a button may be provided on the sideof the message area that pops up a scrolling list of the previousmessages in ascending chronological order.

[0071] The other side of the status bar 230 monitors the status of theconnection of trader client 200 to market server 101. Under normalconditions, this area indicates “Connected,” but may read “Reconnecting”or “Not connected.”

[0072] Trader client 200 may also present trader 50 with a number ofwindows that enable tracking of open orders on the system and a historyof activity for the day. Within these windows each instrument isdisplayed as a Consolidated Summary Line (“CSL”). A CSL representationis a valid expression in Quick Entry Language (QEL) that identifies atleast the option type, best bid, size of best bid, best offer and sizeof the best offer for a particular instrument or contract (e.g. Call May255). Double-clicking on any particular CSL brings up an Option DetailScreen 600 for the CSL's market, illustrated in FIG. 6. The initialstate of the Option Detail Screen 600 is illustrated in terms of whichof the Option Detail Screen's sub-windows are visible may be governedaccording to user preference.

[0073] As illustrated in FIG. 6, a full Option Detail Screen (“ODS”) 600has two components: Expanded Summary Line (“ESL”) 602 and a Market DepthMontage (“MDM”) 604. Whether both components of the ODS 600 areillustrated upon activation depend upon user preference. In one approach(not illustrated), two buttons, “Contract” and “Depth,” could bephysically associated with the ESL, where the “Contract” button togglesthe visibility of an Order Entry dialog box and the “Depth” buttontoggles the visibility of a Market Depth Montage portion of the ODS 600.

[0074] The ESL 602 contains two lines. The first line has a contractsummary line (“NG Call July 265”) and bid/ask fields (“500 2.0 2.5900”). The second line contains a record of the last trade, includingthe price, quantity, side, and timestamp for that contract. The MarketDepth Montage 604 breaks out the display of contract type trades byshowing a complete and detailed view of each quote and order related tothe contract type represented by the ESL 602. As illustrated in FIG. 6,the first line of the MDM 604 has column labels. The second line shows asummary of the best bid and ask, and the quantities at those prices.Subsequent lines in the MDM 604 show ranked summaries of each quote ororder active in the market, one quote or order per line, with the bestbid and ask sharing the top line and each subsequent line becoming lesspreferred. Each line has two columns; the columns rank the bid and askprices. Each column shows the timestamp of when the quote or orderentered the market and the price and quantity of the order. Associatedwith the MDM 604 may be a series of buttons to facilitate Hit 606, Lift608, Bid 610 and Offer 612 operations. The “Hit” button 606 is aone-click way to respond to the best bid. The “Lift” button 608 is aone-click way to respond to the best offer. As illustrated in FIG. 6,orders entered by trader client 200 will be highlighted in the MDM 600(such as by the 3D boxes illustrated in lines 1 and 6 of the MDM 600 ofFIG. 6). Similarly, if any of the orders in the MDM 600 were entered bya trader that does not meet the Right Counterparty Credit Rule, thoseorders will appear differently (perhaps “grayed out”).

[0075] In the approach to trader client 200 illustrated in FIG. 2, inaddition to the main application window, six more windows areillustrated: the Request for Quotes (“RFQ”) window 232, the Order window234, the most active window 236, potential order window 238, workingorder window 240 and filled order window 242. The RFQ 232, order 234 andmost active windows 236 each show a scrolling display of CSL's thatrepresent dynamically updated requests sent by the various traders usingtrader clients 200 a-n in association with market server 101. The RFQ232, order 234 and most active 236 windows start out empty at thebeginning of each trading day and have vertical scrollbars that allowthe user to scroll back from the current time to the beginning of theday. Orders in the potential order 238, working order 240 and filledorder 242 windows may be sorted by option type, month, year, and strikeprice based on user preferences, real time selections and/or filtering.

[0076] The “most active” window 236 presents a CSL for each instrumentthat had activity (a new or updated order, quote, RFQ, or trade) withinthe previous sixty seconds. The rationale for this window is to providea relatively stable display of current activity that does not scroll toofast for traders to be able to select interesting markets when there isa lot of activity. Again, it is known in the art that the time limit canbe increased and decreased by user preference.

[0077] The Potential Order Window (POW) 238 displays a list of ordertemplates that human trader 50 may complete and submit to market server101 and, thus, provides a way for a trader to save commonly used ordersso that future submissions are quick to perform. The trader may selectone or more lines from the Potential Order Window 236 for submission,deletion, or export to Microsoft© Excel© (or other third partyprograms). Selected orders may also be dragged and dropped to otherwindows in trader client 200 where such an operation is functionallymeaningful. For instance, an order cannot be manually moved to theFilled Order Window.

[0078] The Working Order Window (WOW) 240 displays all orders placed bytrader 50 that are open at the current time (including orders that areonly partially filled)(completely filled orders are automatically movedto the filled orders window in real time). The orders are displayedusing CSL in a table, which dynamically grows in size as orders areentered over the course of the day. The rows may also dynamically updateas the orders change status (i.e. partially or complete filled). Thetrader may kill selected orders in the working order window, whichwould—in a preferred approach—bring up a dialog box to confirm the kill.Once confirmed, the “Kill” sends a request to market server 101 to killthe order. When the request is acknowledged, the order changes statefrom “Pending” to “Kill”. When the Kill is completed, the order changesstate to “Killed”.

[0079]FIG. 9A illustrates that the WOW 900 may further include a buttonthat kills all of the orders placed by trader 50. This button, which maybe referred to as a “panic button”, may be useful to immediatelywithdraw trader 50 from all of his positions, if for instance, becauseof quickly changing market conditions (e.g. a declaration of war, anatural catastrophe, pipeline accident, etc.) The trader may similarlyseek to modify a selected order by bringing up a dialog box promptingthe user to enter the modified order information. To assist the traderwith the modification, the fields are preferably initially populatedwith the values of the original order. Only certain fields can bemodified with the other order fields being displayed as read-only.Certain read-only fields can become editable when they become relevantin the current trade.

[0080] If any property of the order is modified other than a lifetime ordownward quantity modification, then the order is not modified at itscurrent place in its respective queue, but rather it is killed after anew order is submitted to the respective queue reflecting all the valuesinput into the dialog box. Thus, the primary functional differences,from the user's perspective, between a modified order and a kill/submitsequence is that a newly submitted order has a new order ID and isentered at the bottom of the order queue, while a modified order retainsits ID and position in the order queue.

[0081] The Filled Order window 242, illustrated in FIG. 2, lists allorders that have been executed during the current day, which dynamicallygrows in size as orders are executed or filled over the course of theday. The order tables may also provide the ability to expand or collapsethe display of information supporting a displayed trade (i.e. displayedif multiple trades were executed to fill or partially fill this order).

[0082]FIG. 7 depicts exemplary information that would be displayed in, aview market window. The entries in this window may be sorted andfiltered according to various criteria selected by the trader 50 usingvarious techniques, such as the multi-layered pull-down menusillustrated in FIG. 3. Similarly, a history view window can be generateddepicting trade history of one particular trader filtered for aparticular date (i.e. 1/1/00), including all the relevant informationregarding the trade. The trades illustrated in the history view can beselected and dragged into other windows, where functionally logical,toward placing a similar order in the active market.

[0083] In general, a new row is added to the bottom of a window eachtime an update is received by trader client 200 from market server 101,unless an instrument's CSL is already in the visible portion of thewindow, in which case the CSL updates in place within the window. Foreach window, detailed information (ODS 600, OEC, ESL 602 and MDMs 604)may be viewed for each trade, as well as summary-only information. Aview of the orders can also be sorted or filtered based on variousparameters including option type, hedging information (expiration date,strike price, ask price, bid price). The view may also show summariesfor all markets, or be filtered to show only markets where the traderhas orders, or only markets where the user has orders at the money. Thetimes displayed in these windows are relative to the time zone of marketserver 101. Orders displayed in these windows may be dragged and droppedinto other windows where such transfer makes functional sense.

[0084] Orders in a “potential order” window do not change state, unlikeorders sent to the market, which change state depending on what happensto them in the market (e.g. acknowledged, partially filled, lied,killed, etc.). Trader 50 can select and send individual or multipleorders from the Potential Order window to market server 101 forexecution. Multi-order submissions are only a shortcut for the user.System 100 actually submits each order individually to market server101, which maintains no connection between simultaneously submittedorders.

[0085] A trader may enter orders, modify any of his working quotes ororders and execute a kill function. Orders, quotes and RFQs can bemanually entered on an order entry card, a Quick Entry Language Line, bydragging and dropping a consolidated summary line (“CSL”) into the“working order” window or “potential order” window, by “hit” or “lift”operations or imported from Excel spreadsheet by a drag-and-dropmechanism. (Conversely, orders can also be dragged from the Potential,Working or Filled Order Windows and dropped into an Excel spreadsheet).The following data is generally common to all RFQ, quotes and orders(bid/ask price and quantity fields not required for RFQ): Contract TypeThe type of option to be traded, usually an underlying commodity typesuch as crude oil or natural as. Side Buying or selling Quantity thenumber of contracts of this type to which this order or quote refersExpiration Date For exchange-traded look-alike contracts, this will bean alphanumeric code for the month field, and a choice of numeric yearvalues from the current year through 19 years out. (In one embodiment,the year defaults to the closest later date (i.e. if order entry occurson Jan. 31, 2000, then a March contract defaults to 2000, while aJanuary contract defaults to 2001). For non-standard contracts, the userspecifies the actual expiration day, month and ear. Strike Price Theprice at which the underlying contract will be delivered in the event anoption is exercised. Bid or Ask Price The price at which someone iswilling to buy the underlying; or The price at which someone is willingto sell the underlying. Premium a Boolean field that indicates that thisleg has the higher value; that is, this is the leg whose rice is tradedupon Hedge A Boolean field that indicates whether to hedge the orderwith futures contracts for the underlying, with the followingparameters: Hedge Delta (“hedge ratio”)-the quantity of hedges to buy,expressed as a percentage of the order quantity Hedge ExpirationDate-the expiration date of the hedges (defaults to expiration date ofthe quote or order). Hedge Price Hedge Quantity-a calculated field whichis the result of multiplying the Order Quantity by the Hedge Delta. Insome approaches this may be rounded to nearest whole number. In otherapproaches a fractional hedge quantity may occur or be entered.Underlying Quantity If changed from default Quantity (Lot Size) for theUnderlying, the contract described by the Order becomes a non-standardcontract. The number of the underlying represented by a quantity 1option contract. (A non-standard contract size whose Quantity fieldequals 1 effectively makes the trade “All or Nothing.”) Settlement TypeIf changed from the default settlement type for the Underlying, thecontract described by the Order becomes a non-standard contract DeliveryPoint If changed from the default delivery point for the Underlying, thecontract described by the Order becomes a non-standard contract OrderType Orders default to limit orders. Stop limit X-As soon as the markettrades at X or lower, submit order to the matching process at X. Fill orKill (FOK) an order that times out after 30 seconds - similar to a quoteexcept that it is one sided and lasts loner One Cancels the Other If oneorder is filled (completely or partially), (OCO) then the other iskilled Time Limit The specified number of seconds (10 seconds is thedefault for a Quote), Days (1 day is the default for the Orders) or GoodTill Cancelled (GTC).

[0086] When a quote, order or market summary line is selected, thetrader may double-click on that entry prompting trader client 200 todisplay an order entry card (FIG. 4) window automatically populated bytrader client 200 with values calculated to optimally execute againstthe selected quote or order. The order entry window also provides meansfor the trade to hit the bid, lift the offer, change a bid price orquantity, change an ask price or quantity and/or save the order to the“potential order” window 238. Once one of the actions above is selected,the trader is then presented with a detailed display of the order to besubmitted, which is reviewed and modified as desired and then the traderspecifies the submit, replace, kill, or potential order actions.

[0087] Of these possible actions, only the replace action may needadditional explanation. For example, if the order being responded to isthe user's order, then the existing order's quantity is decremented bythe quantity being submitted and a new order is placed for thatquantity. If the decrement is unsuccessful, the replace operation isaborted, and a user is informed that nothing happened. If the decrementcould only be partially performed, then that is counted as a successfuldecrement and the new order is submitted but with a quantity adjusted sothat the sum of the decrement orders quantity and the new order'squantity does not exceed the quantity of the decremented order'squantity prior to replacement.

[0088] The main application screen contains a Quick Entry Language Line(QELL), into which commands written in Quick Entry Language (QEL) aretyped. Some QEL sequences cause Order Entry Card (OEC) or New OrderEntry (NOE) screens to be spawned. As illustrated in the version oftrader client 200 depicted in FIG. 2, a Quick Entry Language (“QEL”)Line appears immediately below the menu bar. In particular, the QuickEntry Line allows trader 50 to enter the information for an order usinga basic notation to represent the order parameters. QEL represents afaster entry method to make experienced users of trader client 200 moreproductive.

[0089] The Quick Entry Language (“QEL”) provides a keyboard-basedquick-entry format for fast order creation by experienced users. QEL isprovided as an alternative means of command entry in addition to themore user-friendly, mouse-based, click and type method. It is possibleto express most of the actions relevant to RFQ, quote and order entry ina compact character-oriented format. In addition, some QEL commandsoffer the ability to manipulate or navigate other trader client 200functions. This language is specified as follows:

[0090] [Underlying] Action Quantity Month[Year] Strike Option-type Price[VS Hedged Delta]; or

[0091] Underlying Option-type Action Quantity Month[year] Strike PriceVs Hedged Delta.

[0092] Optional elements are specified in square brackets all otherelements are required to completely specify an instrument. (However,incomplete QEL expressions are often used for specifying a View Marketfilter or partially completing an Order Entry Card.). A non-exclusivelist of “actions” facilitated by system 100 are illustrated in FIG. 8.

[0093] Also illustrated in FIG. 8, QEL supports reordering of elementsso long as there is no possibility of ambiguity in the reordering. QELsupports both net and per-leg hedge deltas. For example, a trader onFeb. 10, 2000 could enter the order express: “Buy 100 June 2000 75 Callsat 15” in these ways:

[0094] B 100 Jun00 75 C 15

[0095] 100 Jun 75 CALL 15B

[0096] CALL B 100 Jun00 75

[0097] The order entry date needs to be specified for this examplebecause QEL year defaults are relative to the date on which they arebeing interpreted. Standard expirations are always month or MonthYear.Non-standard expiration dates are entered and displayed asNSD:Month,Day,Year. Non-standard delivery points and settlement typesare entered and displayed by modifying the underlying symbol withcolon-separated symbols. For example, a Natural Gas contract deliveredin Denver settled in cash might be NG:RKY:$$.

[0098] Human trader 50 can assign a name to any selected custom orderfor future reference. This new type name would be automaticallyrecognized by QEL, appear on the Main Application Screen Contracts andWindows View Market submenus. However, since this assigned name is localto the trader who defined it, the name not recognized by the matchingengine sub-system of market server 101, which would continue to treatthe order as custom.

[0099] The following are examples of the QEL language: ExampleDescription NG V Mar55 C Shows the market on the natural gas march 55call NG B 100 Mar 55 C 230 Buy 100 Mar 55 Call at 230 NG S 100 Mar 55 C230 Sell 100 Mar 55 Call at 230 NG Mar 55 C RFQ Sends a request forquote on the March 55 call

[0100] The user may enter a hot key sequence that performs a pre-definedaction in trader client 200 application. In one approach, there are hotkey sequences for the following actions: (Bid; Offer; Hit Bid; Hit Bidfor X Quantity; Lift Offer; Lift Offer for Y Quantity; Kill Order, KillAll Orders—(enters them into Potential Order window)).

[0101] The Order Entry Card (such as that illustrated in FIG. 4) dialogbox is an entry screen for the specification of orders, quotes and RFQs.Each of the standard contract types (e.g. call, put, butterfly) has itsown OEC. As an example, it someone wished to execute a 50-60-70 callbutterfly, the EOT would capture the whole pattern as a call “butterfly”and trade it as a unit, instead of by specific components. With the QELlanguage, one could simply type “cfly” 50-60-70 and the system wouldunderstand that it is a 50-60-70 call butterfly and a OEC wouldautomatically pop open and complete it based on whatever you waspreviously entered. In addition, an OEC for custom contracts may be usedto enter orders for option types that are not predefined to system 100.Among other information, the OEC should display the name of the contracttype. If the contract is hedged or has a nonstandard delivery point orsettlement type, then the word “Hedged” and the symbols representing thedelivery point or settlement type, respectively should become part ofthe contract name display.

[0102] The OEC may contain one or more contract legs, which aregraphical representations of puts, calls or futures. For instance, thelegs of a contract that are being bought can be represented in one colorwith one graphical prompt and legs being sold could be represented inanother color with another graphical prompt. If a leg does not (yet)represent a bid or offer (for example, the OEC is for an RFQ or isunspecified), then there would be no graphical prompt on the leg. Thelegs have a number of fields, which may be active, passive, orprotected, including Underlying; B/S/R—Buy/SeIURFQ; Quantity; Expirationa Month; Expiration Year; Strike Price; Put/Call; Day; Special (deliverypoints and settlement types); Hedge area (Delta, Date and Price). TheOEC may also include bid and/or ask price fields, except in an OEC foran RFQ.

[0103] The bottom portion of the OEC may optionally contain a set ofbuttons relevant to the context from which the OEC was spawned. Thesecan include view market, potential order, submit order, replace orderand kill order. Some option types require the quantities of each leg tobe in a particular ratio to the other legs and, thus, will have numbersrepresenting the ratios visually associated with each leg.

[0104] An OEC that is intended to be used to enter a new order is calleda New Order Entry screen (NOE). In a NOE, some fields will preferably beauto-filled with default values, which trader 50 can then manuallychange if desired. For example, all quotes may start with their quantityfield's value set to 10. Some fields may also be filled in from thecontext that invoked the NOE.

[0105] In the event a hedging contract is entered into trader client,client 200 determines whether the hedge ultimately results in the buyingor selling of hedge contracts. In the first event, a Buy Call is equatedto Sell Hedge; Sell Call is equated to a Buy Hedge; Buy Put is equatedto a Buy Hedge; and Sell Put is equated to a Sell Hedge. Where the hedgeis multi-legged, the net delta is actually the traded order. Forexample, a Buy of 50 Call Butterflies with a 18/12/10 delta operateslike this:

[0106] B 50 Mar01 50/55/60 CFLY 10D

[0107] B 50 Mar01 50 C/Sell 9 hedge

[0108] S 100 Mar01 55 C/Buy 12 hedge

[0109] B 50 Mar01 55 C/Sell 5 hedge

[0110] Therefore, the Net Hedge=Sell 2, 2D. Thus, trader client 200should enter the hedge for an entire multi-leg order as a net hedgedirectly as a single hedge on one leg of the Order, and need not specifyseparate hedges for each leg. This minimizes the number of unnecessaryorders placed on the market server. In one approach, the system mayallow users to either enter a delta and compute a whole or fractionalhedge quantity or enter a hedge quantity and compute either a whole orfractional delta. This gives users the choice to trade with either thedelta (see FIG. 10A for the OEC example) or the hedge quantity (see FIG.10B for the OEC example) as the deciding factor in a trade. Preferably,a computed delta will be rounded to the second decimal place (really thefourth decimal place because delta is actually a percentage figure).There will be no need to round the hedge quantity once the delta isrounded because that rounding will ensure a rounded hedge quantityresult.

[0111] When one executes an option trade, one uses a “delta” todetermine what amount of the underlying contract one should buy or sellto offset the trade one did in the option in order for one to have lessrisk. As an example, suppose there is a June 250 call, with a 10 Deltaand one is buying 100 of it. This means it is just a percentage (10%).So one would execute 10% of the underlying against the call. So if onebuys 100 June 250 calls, one is going to hedge it by selling 10 Junefutures. Traditionally in the market, one would buy 100 June 250 callsin the options ring and will than turn around to the futures ring andsell 10 June futures. Traders often execute a “laid up”—that is thatthey execute it as a package, because they wish to “hedge” themselvesand relieve themselves of this extra futures risk. In the presentsystem, we could just click a Hedge button, which would open up HedgeFields that are related to each of the months. Thus, since one ishedging with the underlying futures, if one executes a June 250 call anda June 300 call spread in the same month, one would only have to hedgeit once because one is only hedging June futures. But if one did acalendar spread (lets say a June 250 and a July 300 call), than he istrading two different months and, one would have to hedge the Junefutures and the July futures separately. In the first example, they arein the same month, and one could just net out the hedge.

[0112] In the preferred example of a fractional hedge approach, thetrade will only match if the delta matches, partial fills might have tobe re-submitted as with alternate delta mixes in order to achieve thedesired result. For Example:

[0113] Trader A: B 100 Mar 75 Calls w/27 Delta: hedge=27 futures

[0114] Trader B: S 34 Mar 75 Calls w/27 Delta: hedge=9.18 futures

[0115] These two can trade in one of two ways:

[0116] 1) Fractional Hedge Method:

[0117] Trader B hits bid (allowing for fractional hedge).

[0118] a. Match: 34 Mar 75 Calls w/27 Delta: Hedge=9.18

[0119] b. Partial fill leaves Trader B with an outstanding order:

[0120] B 66 Mar 75 Calls w/27 Delta: hedge=17.82

[0121] 2) Fractional Delta Method:

[0122] Trader B entered their order with an exact hedge of 9:

[0123] a. Trader A must first cancel their outstanding bid for 100

[0124] b. Trader A must hit Trader B's order

[0125] c. Match: 34 Mar 75 Calls w/26.471 Delta: Hedge=9

[0126] d. Trader A must re-enter their original order for the remaining66

[0127] So, under this approach and every trade can go in eitherdirection. An equation that can be derived from the above is as follows:D(Q)=H or H/Q=D (where Q=Option Quantity; D=Delta; and H=HedgeQuantity).

[0128] In this approach, the fractional hedging contracts must enter themarket server based on “like deltas” not “like hedges.” This approachinsures that trades match when the initial quantities, and thus thehedge quantities don't match. Once a trade matches the hedge quantitieswill be the same, however, initially the delta will be the determiningfactor.

[0129] These fractional instruments may lend to the provision ofadditional functionality in the market views. For instance, giving usersthe ability to see identical hedged options in the market with differentdeltas. (i.e.: View every Hedged March 2001 SO Call). In one approach,after trader 50 opens an OEC, ESL or MDM for a hedged option, they canhit a button, which opens a small filter window showing the same option,but hedged with other deltas on the 'system. This would allow the traderto participate in alternate trades where the deltas don't initiallymatch their delta. Essentially, this may be implemented as a filterbased on the QEL with the option quantity, delta, futures quantity, andbuy/sell as wild cards. It would also be possible to add variables tothis “filtered” view, such as show all hedged calls; show all hedgedMarch 2001 50 calls, etc.).

[0130] Some instrument types require the specification of quantityratios between contract legs. On input to the trader client 200, allratio trades will adjust their ratio and quantities automaticallyaccording to the least common divisor between the ratio elements. Forexample, an order for 200 2×4 Call Spreads will be entered as 400 1×2Call Spreads. This will reduce the proliferation of disjoint ratiomarkets and help to increase liquidity in market server 101.

[0131] Custom option types may be specified—these are any sequence ofput, call and “look-alike” futures contract legs and hedges that do notmatch the sequence (and their inter-leg constraints) that compose thesystem-defined option types. Custom orders allow the specification ofratios between each of their constituent legs.

[0132] An RFQ is a message broadcast to all interested marketparticipants for price and quantity quotations on a particularunderlying commodity (i.e. crude oil). Generally, an RFQ is sent whenthere is no activity (outstanding quotes or orders) relating to anunderlying, though it is also appropriate to send an RFQ when theactivity is low. Once all the required fields of an RFQ have beenspecified by a trader, it may be sent to market server 101. If themarket server accepts the RFQ, the RFQ appears in the RFQ display of allother trader clients logged into market server 101. In one approach tothe present invention, as the RFQ is sent to market server 101, traderclient 200 also generates a potential order for that RFQ that requiresmanual insertion of only bid/ask price and quantity fields to make it avalid order or quote which can then reside in the potential order windowof the trader client.

[0133] When market server 101 sends a message to trader client 200, itis available for viewing by the trader in summary of detail forms.Traders may even scroll through all messages received in a particularsession.

[0134] Trader 50 may specify and save various application preferencesthat affect the operation of that trader's trader client 200. System 100automatically saves trader's preferences after the user changes theirvalues. For instance, these changeable preferences may include: TimeZone; Quote Expiration Time; FOK Expiration Time; Default QuoteQuantity; Default Limit Order Quantity; and windows illustrated whendisplaying Option Detail Screen.

[0135] Alerts are dialog boxes that pop up on a user's screen that theuser must affirmatively close. The user can configure trader clientpreferences to indicate which alerts should be received (executions,rejections, kills and system status messages). All alert messages appearin the status bar, regardless of the user's preference settings.

[0136] Before executing a user's request to initiate a significanttransaction or a state change, the system can be configured to ask theuser whether to proceed. This is a precaution against user mistakes. Theconfirmation is in the form of a pop-up dialog. Often the pop-up dialoglooks like an order entry screen. In some approaches, confirmation canbe turned on or off as a user preference.

[0137] Trader client 200 may also provide an API for a user to send thedetails of a potential order prior to submission to a third partyanalytics package. The third party package can calculate a bid and askprice then can be inserted into the order details. The user may thenreview the results, and submit the order.

[0138] Administrator client 300 provides a computer interface fortrading firm administration staff to manage traders and counterparties.Among other functions, administrator client 300 should manage traders,firms, underlyings and contract specifications, send and receive systemmessages, kill orders and reverse trades for traders and monitor thestatus of users and market server 101.

[0139] As an adjunct to the various monitoring capabilities,administrator client 300 can also log trades for later analysis. Forinstance, administrator client 300 may provide both current andhistorical information of trades and activity by firm-related traders.In one approach, the reports could be either viewed online or downloadedinto a third party spread-sheet program, such as Microsoft© Excel©.

[0140] Server administrator 400 provides a computer interface formanaging users, option types, underlying commodity types, and systemmonitoring.

[0141] In operation, trader 50 launches trader client 200 on the localcomputer and enters a user ID. Trader client 200 then retrieves a locallist of instruments that trader 50 is authorized to view and/or trade. Alist of allowable contract types is loaded into trader client 200 frommarket server 101 each time the trader client 200 starts up. Thisunderlying list having been established and perhaps previously modifiedby market server 101 during a previous session, trader 50 selects anunderlying commodity to view or trade during the present computersession and provides his password associated with the user ID. (Theunderlying or contract type is generally fixed for a session with allsubsequent operations referring to that type.) The login request is thensubmitted to market server 101, which verifies the User ID, Password,and rights of trader 50 to trade in the selected underlying market. Iftrader 50 passes security measures, then market server 101 setsentitlements, retrieves the default user preferences, displays one ormore application screens in a layout determined by the retrievedpreferences. Market server 101 displays all pending messages for trader50 received since the last log out.

[0142] Basic Path for Submitting A Working Order:

[0143] Trader enters all required fields on the Order Entry Card.

[0144] Trader client 200 validates the field values against theapplicable Order Validation rules based on current knowledge.

[0145] The user submits the quote or order to market server 101.

[0146] Market server 101 authenticates and validates the submissionagainst the order validation rules.

[0147] The system acknowledges the quote or order to the user.

[0148] The accepted quote or order is submitted to the Order Matchingservice.

[0149] If matched, the order executes, and trade confirmation messagesare sent to each trade's counterparty.

[0150] Market server 101 then modifies the quote or order according tothe trade activity.

[0151] The market server 101 broadcasts the resulting status to allinterested market participants.

[0152] Quote or Order is Rejected by Validation Rule. If market server101 does not successfully authenticate or validate the quote or order,market server 101 sends a rejection message to the submitting user.

[0153] Market server 101 is then closed.

[0154] The concept of “negative pricing” raises particular problems whentrying to move an options trading system from a trading floor to an EOTwhen, in trading certain option strategies (combinations) the price ofthe first leg that one is buying versus the prices of the leg one isselling in the combination could be a net value of zero or close tozero. A trader can use a negative bid or offer when he is quoting atrade whose opposite sides are approximately equal in value. Thisscenario can occur in the following trade types:

[0155] straddle spread, fence, calendar call spread, calendar putspread, calendar fence, ratio call spread, ratio put spread, ratiofence, 3way, fence strip.

[0156] As an example, if there is a May 400 call (c) and June 450 call(c) and someone is interested in trading in combination (this is knownas a Calendar Call Spread and involves the simultaneous purchase of oneof these options and sale of the other). Further assuming that the valueof the May call is $50 and the value of the June call is $100. The valueof the spread is therefore $50 (because you are buying one option andselling the other). If a trader wishes to make a $5 profit trading thisspread, regardless of whether he intends to buy the June 450c or sellthe May 400c (buy the spread) or sell the June 450c and buy the May 400c(sell the spread), he would make the following 2-sided quote:

[0157] May400c/June450c $45 bid $55 offer

[0158] Which means he wants to either, buy the June call and sell theMay call and pay $45 to execute this trade (it's worth $50 so it's agood deal). Or sell the June call and buy the May call and receive $55to execute this trade (it's still worth $50). Now suppose the May 400cis worth $99 and the June 450 Call is worth $100 (the spread is worth$1). If the same trader wanted to make a two-sided quote that wouldensure a $5 profit regardless of whether he intends to buy or sell thespread he would enter the following bid and offer:

[0159] May400c/June450c $−4 bid $6 offer

[0160] Which means either he will buy the June call and sell the Maycall and receive $4 (he should have paid $1 for it, a $5 profit). Or hewill sell the June call and buy the May call and receive $6 (spread isstill worth only $1). It is important to recognize that the followingtwo quotes are mirror images of each other and create the identical2-sided market. The only difference is that the first quote uses theJune call to describe the trade while the second uses the May call.May400c/June450c −4 Bid 6 Offer=May400c/June450c −6 Bid 4 Offer, becausethis trade means either buy the May call sell the June call and receive$6 or sell the May call buy the June call and receive $4.

[0161] Theoretically it's possible for there to be a negative bid andnegative offer on a particular option spread (−50 bid −40 offer). Thiswould be an usual way for a trader to make a quote. Applicants havetherefore established a rule that a trader can enter a 2-sided negativemarket, however, that order will be displayed as it's positive mirrorimage in the Marketplace window. For example, a trader may enterJan200p/Feb300p −$15 bid −$5 offer. The marketplace would displayJan200p/Feb300p 5 bid 15 offer, again a mirror trade of the originaltrade.

[0162] To overcome the many hurdles of negative pricing in anelectronically traded options system, we have created a series of rulesthat should preferably be followed.

[0163] Trader Workstation (Front End):

[0164] Single negative bids (without offers) or offers (without bids)are not displayed.

[0165] Double negatives are not displayed.

[0166] In the event that there is a negative bid with a positive offerit is displayed in terms of the lower strike.

[0167] All ESL's establish for themselves a rule of the premium strikeit uses to express negatives and positives at the point it is opened. Inother words, whatever the TW is displaying, according to the Rules 0 and0, at the time the ESL is opened, that will establish the rule for howit will be displayed for as long as it is opened.

[0168] MDM is an extension of the ESL; therefore the open ESL hasalready established the rule for the MDM.

[0169] OEC, when created from the ESL (by pressing: ^ , Hit, Lift, bid,offer), will reflect the rules of the open ESL.

[0170] The rules of the OEC when created from scratch, will beestablished by the order the user enters at that moment.

[0171] Working Order Window (WOW)

[0172] The WOW rules are based on whatever the rules were entered forthe original order, and those rules will last forever.

[0173] Market WOW rules are based on whatever the rules were entered forthe original order and those rules will last forever.

[0174] Filled Order Window (FOW):

[0175] The FOW is always displayed in terms that would result in apositive buy or sale. No trades ever occur at a negative price. Theinstrument description associated with the execution must be displayedin such a way to make the trade price positive.

[0176] Market Place (Back End):

[0177] All orders are displayed in terms of the lower strike in theearliest month.

[0178] An implied bid or offer is an order for any SPREAD that isgenerated by the system to help execute a users trade. For example, ifthe user is trying to sell a September 50/60 Call Spread for a price of10 (sell the 50 strike and buy the 60 strike). As soon as the order isentered in the system by the user, the system starts searching for anybids or offers currently in the system, for either one of the legs inthat particular trade (in our example the September 50 or 60 call) tooffset the trade against. If for example, the system finds a 55 bid forthe September 50 call, the system would automatically generate a 65 bidfor the September 60 calls. If some other user happens to sell theSeptember 60 calls for 65 then the system would automatically sell the50 calls to the user who is bidding 55. The system using implied bidsand offers has now executed the call spread for the price of 10.

[0179] Thus, while there have been shown, described, and pointed outfundamental novel features of the invention as applied to a preferredembodiment thereof, it will be understood that various omissions,substitutions, and changes in the form and details of the devicesillustrated, and in their operation, may be made by those skilled in theart without departing from the spirit and scope of the invention. Forexample, it is expressly intended that all combinations of thoseelements and/or steps which perform substantially the same function, insubstantially the same way, to achieve the same results are within thescope of the invention. Substitutions of elements from one describedembodiment to another are also fully intended and contemplated. It isalso to be understood that the drawings are not necessarily drawn toscale, but that they are merely conceptual in nature. It is theintention, therefore, to be limited only as indicated by the scope ofthe claims appended hereto.

What is claimed is:
 1. A method for electronically trading a financialinstrument, comprising: entering a bid order for the financialinstrument and placing the bid order in a bid queue associated with abuyer who maintains a list of sellers to sell the financial instrumentto; entering an ask order for the financial instrument and placing theask order in an ask queue associated with a seller who maintains a listof buyers to buy the financial instrument from; matching the bid orderand the ask order to execute a trade between the buyer and the seller;and executing the trade if a price of the bid order is not less than aprice of the ask order, and if the buyer is on the list of buyers andthe seller is on the list of sellers.
 2. The method of claim 1, furthercomprising matching a next bid order in the bid queue and the ask orderif the buyer is not on the list of buyers or the seller is not on thelist of sellers.
 3. The method of claim 1, further comprising matching anext ask order in the ask queue and the bid order if the buyer is not onthe list of buyers or the seller is not on the list of sellers.
 4. Themethod of claim 1, further comprising matching a next bid order in thebid queue and a next ask order in the ask queue if a price of the askorder is greater than a price of the bid order.
 5. The method of claim1, further comprising electronically screening sellers and buyers suchthat only acceptable sellers are placed on the list of sellers andacceptable buyers are placed on the list of buyers.
 6. The method ofclaim 1, wherein neither the bid order nor the ask order is removed fromthe bid queue or the ask queue, respectively, if there is no match. 7.The method of claim 1, further comprising activating a virtual button ona display screen to immediately cancel all bid orders or ask orders. 8.A system for electronically trading a financial instrument, comprising:a memory storage for storing machine-readable instructions; and aprocessor programmable to execute the machine-readable instructionsretrieved from the memory storage for a) entering a bid order for thefinancial instrument and placing the bid order in a bid queue associatedwith a buyer who maintains a list of sellers to sell the financialinstrument to; b) entering an ask order for the financial instrument andplacing the ask order in an ask queue associated with a seller whomaintains a list of buyers to buy the financial instrument from; c)matching the bid order and the ask order to execute a trade between thebuyer and the seller; and d) executing the trade if a price of the bidorder is not less than a price of the ask order, and if the buyer is onthe list of buyers and the seller is on the list of sellers.
 9. Thesystem of claim 8, wherein a next bid order in the bid queue is matchedwith the ask order if the buyer is not on the list of buyers or theseller is not on the list of sellers.
 10. The system of claim 8, whereina next ask order in the ask queue is matched with the bid order if thebuyer is not on the list of buyers or the seller is not on the list ofsellers.
 11. The system of claim 8, wherein a next bid order in the bidqueue is matched with a next ask order in the ask queue if a price ofthe ask order is greater than a price of the bid order.
 12. The systemof claim 8, wherein sellers and buyers are screened electronically suchthat only acceptable sellers are placed on the list of sellers andacceptable buyers are placed on the list of buyers.
 13. The system ofclaim 8, wherein neither the bid order nor the ask order is removed fromthe bid queue or the ask queue, respectively, if there is no match. 14.The system of claim 8, wherein a virtual button is activated on adisplay screen to immediately cancel all bid orders or ask orders.
 15. Amethod for electronically trading options contracts and for hedging theoptions contracts with underlying contracts, comprising: entering a buyorder for options with a first hedge delta to represent a first numberof underlying contracts; entering a sell order for options with a secondhedge delta to represent a second number of the underlying contracts;matching the buy order and the sell order to execute a trade; andexecuting the trade if the first hedge delta is equal to the secondhedge delta.
 16. The method of claim 15, wherein the first hedge deltais a fractional number.
 17. The method of claim 15, wherein the secondhedge delta is a fractional number.
 18. The method of claim 15, whereinthe first number of underlying contracts is a fractional number.
 19. Themethod of claim 15, wherein the second number of underlying contracts isa fractional number.
 20. A system for electronically trading optionscontracts and for hedging the options contracts with futures contracts,comprising: a memory storage for storing machine-readable instructions;and a processor programmable to execute the machine-readableinstructions retrieved from the memory storage for a) entering a buyorder for options with a first hedge delta to represent a first numberof underlying contracts; b) entering a sell order for options with asecond hedge delta to represent a second number of the underlyingcontracts; c) matching the buy order and the sell order to execute atrade; and d) executing the trade if the first hedge delta is equal tothe second hedge delta.
 21. The system of claim 20, wherein the firsthedge delta is a fractional number.
 22. The system of claim 20, whereinthe second hedge delta is a fractional number.
 23. The system of claim20, wherein the first number of underlying contracts is a fractionalnumber.
 24. The system of claim 20, wherein the second number ofunderlying contracts is a fractional number.